繼昨天 D7 - 願連假後，我們還記得討論的內容
我們討論到了 Product Backlog 的內容對於開發重要的程度後
今天要跟諸君討論 如何寫一個好的 user story (請恕我調整一下標題本來分上下集，但感覺大家會不知道這篇再說明 userStory)

不知道大家覺得這樣的 user story 有沒有幫助...

如果我是 Scrum Master 的話，我會想要跟大家討論一下 mvp 與技術債的問題，因為有遇到類似的狀況覺得很重要。

這還真的有寫跟沒寫一樣，效果跟留白 "新增更詳細的敘述..." 有得比

在探討 user story 前，要先跟大家講解一下 user story 是什麼

變成我比較習慣的中文來描述的話
如果我是 OOOO ，我會希望有 XXXXX，因為 !@#$%^&*()_+ 很重要

那究竟要如何寫好 user story 呢？
直接舉個更生活化的案例讓大家來體驗一下。
假設我是證劵公司底下的工程師，我接到 PO 說要討論這則 user story

如果我是 股票操盤手
我希望有 股票分析功能
因為 我可以分析股票

我可能會趁 PO 在分享螢幕時，更新我的 linkedIn open to work
那要如何寫出一個好的 user story 呢

這時候我們就要善用一些動詞、形容詞和同理心
直接上成品

如果我是 動輒百萬的股票操盤手 __形容詞參戰
我希望有 能自動更新國際指標報表 __動詞加入
因為 這年頭工作不好找，務必要降低任何錯估的可能 __同理心充值

在這樣的描述下，我們接下來開發功能是不是腦內就有更多的功能並且可以將 acceptance 列的相對詳細
例如：
功能的實時性(更新頻率)、相關指標的篩選器(方便觀看)、可能需要有高級的 AI model提供人員參考...諸如此類。

且當我們透過一些修飾字(形容詞)來描述我們的用戶時，可以更加強烈
例如
如果我是動輒千萬的股票操盤手 形容詞更改
這時候這位縱橫股市的操盤手可能需要的就不是單一的功能，
可能是需要一個團隊組織來協助他處理股票市場的大小事

甚至有些特別的團隊會培養自己的 persona 來當作熟悉的 user 朋友

不過在陷入如何寫好 user story 的苦惱前請大家記得幾件事情

• user story 是拿來溝通的
• user story 不是唯一的需求文件
• user story 讓團隊開始進行對話
• user story 讓團隊不會忽略是幫誰做事
• user story 方便記憶與回想
• user story 不是每個功能都要有
• user story 有很多種思考模式，如 IMPACT MAPPING、POV

參考資料：
之前上的一些課程(CSM & Agile Summit)和一路跌跌撞撞的經驗